home *** CD-ROM | disk | FTP | other *** search
/ ftp.cs.arizona.edu / ftp.cs.arizona.edu.tar / ftp.cs.arizona.edu / icon / newsgrp / group94b.txt / 000114_icon-group-sender _Sun Nov 20 21:40:31 1994.msg < prev    next >
Internet Message Format  |  1995-02-09  |  4KB
  1. Received: by cheltenham.cs.arizona.edu; Sun, 20 Nov 1994 15:13:34 MST
  2. To: icon-group-l@cs.arizona.edu
  3. Date: 20 Nov 1994 21:40:31 GMT
  4. From: ruiter@ruls41.fsw.LeidenUniv.nl (Jan-Peter de Ruiter)
  5. Message-Id: <3aofof$f5m@highway.LeidenUniv.nl>
  6. Organization: Leiden University, The Netherlands
  7. Sender: icon-group-request@cs.arizona.edu
  8. Subject: optional typing in Icon (longish)
  9. Errors-To: icon-group-errors@cs.arizona.edu
  10.  
  11. Hi,
  12.  
  13. I've just finished reading (first pass) the book "The Implementation
  14. of the Icon Programming Language" by Griswold & Griswold and I can 
  15. recommend any Icon programmer to read this book too. Not only is it 
  16. beautifully set, highly readable and very informative, it also gives 
  17. a whole new view on how powerful and sophisticated the language actually 
  18. is.
  19.  
  20. Having said this, I remember Tim Peters (who used to honor the
  21. Icon newsgroup with helpful advice, and who did some outrageous 
  22. programming in Icon) saying in a private email to me that it
  23. is a pity that the performance of Icon prevents the Icon 
  24. compiler/interpreter to be written in Icon.
  25.  
  26. This performance issue is one that I gladly take for granted seeing
  27. how much time I save in developing Icon programs (as opposed to, say, 
  28. C programs) but I also agree with Tim that it would be nice to be 
  29. able to bootstrap Icon. 
  30.  
  31. Being somewhat wiser after having read the book, I also fully understand
  32. why the Icon compiler depends so heavily on run-time checks. 
  33.  
  34. But I started analysing some of my Icon programs that I would like 
  35. to speed up, and noticed that many times *I* know (as opposed to the
  36. compiler) that variable V is only used as {integer, string, real etc}
  37. or as {list_of_integer, list_of_strings, table_of_strings_and_ints,
  38. etc }. So my question is: what do you think of the option to add
  39. *optional* type declarations to Icon? By optional type declarations 
  40. I mean something along these lines:
  41.  
  42. global count : table(string,integer,0)
  43. procedure main()
  44.     local f : file
  45.     f := open("wordlist")
  46.     concordance(f)
  47. end
  48. procedure concordance(f : file)
  49.     local s : string
  50.     while s := read(f) do count[s] +:= 1    
  51. end
  52.  
  53. Please realise that the syntax does not matter here - the idea
  54. is that if I know that s is only going to be used as string, 
  55. I can declare it to be a string-only variable. I don't *have* to,
  56. but I can. 
  57.  
  58. BTW, the typing scheme could of course allow for things like:
  59.  
  60.     local count : table(list(string),list(real),[])
  61.  
  62. in other words, type embeddings could be allowed as well.
  63.  
  64. This optional typing would of course be truly optional. That is,
  65. any Icon program without type declarations would run without
  66. modification. 
  67.  
  68. At the moment, I see great advantages in such an extension of 
  69. Icon. Allowing type declarations is not the same as enforcing
  70. them, and nobody would be forced to use them. Programs could
  71. be developped using dynamic-type variables as they are now, and
  72. later be optimised by adding types. 
  73.  
  74. I am aware of the fact that this would mean an extensive modification
  75. of both the Icon compiler and interpreter. Also, I understand that
  76. problems arise with mixing typed and untyped variables. In order to
  77. allow for mixtures, a special type declaration (e.g. 'dynamic') 
  78. could be used to allow for mixing typed and dynamic variables.
  79.  
  80. Extending the Icon compiler would be a lot of work, I guess, but
  81. the technology is already there - most compilers use type checking
  82. and as you know probably better than me, the theory of typing
  83. systems is quite advanced. For the runtime environment, I am
  84. not sure excactly what the consequences would be.
  85.  
  86. The specific questions I have for the Icon community are:
  87.  
  88. o How much optimisation opportunities will arise from having
  89.   variables with a fixed type.
  90.  
  91. o How much speed & size performance gain could be expected from 
  92.   this.
  93.  
  94. o Could a typed variable also lead to more efficient generators
  95.   and backtracking (over typed variables of course).
  96.  
  97. o Could a version of the Icon runtime environment be developed
  98.   that gives information on how often the type of all variables 
  99.   changes during program execution (in order to obtain reliable
  100.   statistics on how often variables are, in effect, of fixed type)
  101.  
  102. o What do you generally think about this idea.
  103.  
  104. Any comments welcome. Please do not interpret this posting
  105. as criticism on Icon, for it is not intended as such. 
  106.  
  107. Greetings,
  108.  
  109. Jan